This project showcases the end-to-end execution of a vulnerability management program, from assessment and scanning to remediation and reporting. I document and simulate the entire implementation and complete a first full lifecycle to demonstrate practical skills. The work aligns with three primary frameworks: NIST SP 800-53 Rev. 5 (RA-5 vulnerability scanning, SI-2 flaw remediation, CM-6 and CM-7 secure configuration and least functionality), the NIST Cybersecurity Framework 2.0 (Identify, Protect, Detect, and Govern activities with continuous monitoring in Maintenance Mode), and ISO/IEC 27001:2022 Annex A control A.8.8 Technical Vulnerability Management. In production environments, timelines vary by organizational size, scope, and maturity, and full rollout can span multiple quarters.
The implementation process reflects real-world practice, moving systematically from an initial baseline to a fully operational program.
Inception State: The organization begins with no established policy, procedures, or tools for identifying, assessing, or remediating vulnerabilities.
Completion State: A formal vulnerability management policy is established, stakeholder alignment is achieved, and a complete vulnerability assessment and remediation cycle is executed across the organization’s environment.
A mid-sized company operating roughly 200 servers. The GRC team has procured Tenable to reduce organizational risk related to software and operating system vulnerabilities and to anchor scanning, reporting, and governance workflows.
- Tenable
Enterprise-grade vulnerability management platform used for asset discovery, assessment, and risk prioritization. - Microsoft Azure Virtual Machines
Deployed as both Nessus scan engines and target hosts, enabling scalable, cloud-based testing and validation. - PowerShell
Used to automate remediation tasks, apply configuration changes, and verify system hardening across Windows environments.
- Vulnerability Management Policy Draft Creation
- Mock Meeting: Policy Buy-In (Stakeholders)
- Policy Finalization and Senior Leadership Sign-Off
- Mock Meeting: Initial Scan Permission (Server Team)
- Initial Scan of Server Team Assets (Discovery)
- Vulnerability Assessment and Prioritization
- Mock Meeting: Post-Initial Discovery Scan (Server Team)
- Distributing Remediations to Remediation Teams
- Mock CAB Meeting: Implementing Remediations
- Remediation Round 1: CVE-2013-3900
- Remediation Round 2: Outdated Wireshark Removal
- Remediation Round 3: Guest Account Group Membership
- Remediation Round 4: Insecure Protocols & Ciphers
- Remediation Round 5: Windows OS Updates
- Remediation Round 6: ICMP Timestamp
- First Cycle Remediation Effort Summary
This phase focuses on creating an initial Vulnerability Management Policy to establish a foundation for stakeholder engagement. The draft defines the program scope, roles and responsibilities, and remediation timelines. It serves as a working document that may be refined through feedback from relevant departments to ensure the policy is both practical and enforceable prior to final approval by executive management.
In this phase, a meeting with the server team is conducted to introduce the draft Vulnerability Management Policy and evaluate their ability to meet remediation timelines. Feedback from stakeholders informs adjustments to the policy, such as extending the critical vulnerability remediation window from 48 hours to one week, ensuring a collaborative and practical implementation approach.
Click to View Meeting Transcript
Meeting Transcript
Danny: Good morning, Luca. How’s everything been recently? I know everyone’s been busy these last few weeks.
Luca: Good morning, Danny. Yeah, it’s been a bit hectic, but we’re hanging in there. Thanks for asking. I had a chance to read through the policy draft, and overall it makes sense. However, with our current staffing, we can’t meet the aggressive remediation timelines, especially the 48-hour window for critical vulnerabilities.
Danny: I totally understand. It is a bit aggressive, especially to start. Perhaps we can extend the critical remediation window to one week for now. We can reserve the 48-hour window for truly severe zero-day vulnerabilities.
Luca: That sounds reasonable. We appreciate the flexibility. Can we have a bit of leeway in the beginning as we get used to the remediation and patching process, just for the first few months?
Danny: Absolutely. After the policy is finalized, we’ll officially start the program, but all departments will have about six months to adjust and become comfortable with the new process. Does that sound fair?
Luca: Thanks, Danny. We’ll do our best. I appreciate you including us in the decision-making process. It really helps us feel like we’re part of the solution.
Danny: Of course. We’re all in this together. Thanks for working with us.
Luca: No problem. Thanks for the short meeting.
Danny: Yeah, those are my favorite types. Bye now.
Luca: See you later.
After gathering feedback from the server team, the Vulnerability Management Policy is revised to address aggressive remediation timelines. With final approval from senior leadership, the policy becomes the guiding document for the program, ensuring organizational compliance and providing a clear reference for resolving any disputes or pushback.
In this phase, the vulnerability management team collaborates with the server team to initiate scheduled credentialed scans. A compromise is reached to scan a single server first, monitoring resource impact and using just-in-time Active Directory credentials to ensure secure, controlled access.
Click to View Meeting Transcript
Meeting Transcript
Danny: Morning, Luca.
Luca: Good morning! I heard you’re ready to conduct some scans.
Danny: Yep. Now that our Vulnerability Management Policy is in place, I wanted to get started on conducting some scheduled credentialed scans of your environment.
Luca: Sounds good to me. What’s involved? How can we help?
Danny: We’re planning to schedule some weekly scans of the server infrastructure. We estimate it’ll take about 4 to 6 hours to scan all 200 assets. We’ll need you to provide administrative credentials, which will allow the scan engine to remotely log into the targets and better assess them.
Luca: Whoa, hold on. What does scanning actually entail? I’m a bit worried about resource utilization. Also, you want admin credentials to all 200 machines? That doesn’t sound safe.
Danny: Those are valid concerns. The scan engine sends traffic to the servers to check for certain vulnerabilities like examining the registry, detecting out-of-date software, or identifying insecure protocols and cipher suites. That’s why credentials are required.
Luca: I see. Well, as long as it doesn’t bring the servers offline, I guess we should be okay.
Danny: Absolutely. Let’s just scan a single server for now and monitor resource utilization.
Luca: Not a bad idea.
Danny: Great. Also, for the credentials, can you set up something in Active Directory? Create credentials that are disabled until we’re ready to scan, enable them just before the scan, and then deprovision or disable the account afterward. Kind of like a just-in-time access situation.
Luca: That sounds good. I’ll ask Susan to get started on the automation for the account provisioning and get back to you once the credentials are set up.
Danny: Awesome! Thanks so much! See you later!
Luca: See you later.
An insecure Windows Server is provisioned to simulate the server team's environment. Known vulnerabilities are intentionally introduced, then an authenticated (credentialed) Nessus scan is executed against the host. Scan results are exported and archived for tracking and remediation planning in subsequent steps.
Following the initial scan, we analyzed vulnerabilities for severity, exploitability, and remediation effort, then prioritized six items by overall impact and ease of remediation, placing issues with clear exploitation paths or compounding findings at the top.
| Priority | Vulnerability | Description | Rationale |
|---|---|---|---|
| 1 | CVE-2013-3900 – Certificate Padding Check | Enable certificate padding validation to prevent signature spoofing. | High-impact trust bypass with a simple registry-based mitigation. Immediate reduction of risk that malicious binaries appear trusted. |
| 2 | Third-Party Software Removal (Wireshark) | Remove non-essential network analysis tools from production systems. | Multiple Critical/High findings for unsupported and vulnerable Wireshark builds. One action removes a cluster of vulns and insider misuse risk. |
| 3 | Windows OS Secure Configuration (Guest Account Group Membership) | Verify Guest is disabled and not in privileged groups. | Flagged as High severity misconfiguration. Very fast to fix and reduces lateral-movement and unauthorized-access risk. |
| 4 | Windows OS Secure Configuration (Protocols & Ciphers) | Disable deprecated SSL/TLS versions and weak ciphers; replace weak or self-signed certs. | Mitigates MITM and downgrade attacks across services (TLS 1.0/1.1, SWEET32, weak/medium ciphers, untrusted certs). Moderate effort due to testing and potential service impact. |
| 5 | Windows OS Updates | Apply missing patches and cumulative updates. | Ongoing hygiene to close known CVEs. Effort varies by patch set; keep as a rolling baseline after the highest-risk configuration fixes. |
| 6 | ICMP Timestamp | Filter ICMP timestamp requests/replies. | Easy fix with low operational impact, but low severity. Address after higher-risk items. |
Why this order: The scan shows concentrated risk around Wireshark (Critical/High, unsupported) and a High-severity Guest group issue, so both move ahead of protocol hardening and general patching. CVE-2013-3900 remains first due to its high impact and trivial remediation.
The server team and vulnerability management team reviewed the scan results, confirming outdated software, insecure accounts, and deprecated protocols. Remediation packages will be assembled with owners, rollback plans, and maintenance windows, and prepared for submission to the Change Control Board (CAB).
Click to View Meeting Transcript
Meeting Transcript
Danny: Morning, Luca. How are you doing?
Luca: Not bad for a Monday. You?
Danny: Still alive, so no complaints. Before we get into vulnerabilities, how did the scan go on your end? Any outages or resource spikes?
Luca: The scan went well. We monitored it closely. Aside from the increase in open connections, we would not have known a scan was running.
Danny: Good news. That is what we expected. We will keep monitoring, but I do not anticipate resource issues. Mind if I jump into the findings?
Luca: Sure, go ahead.
Danny: Sharing my screen now. Most of these findings are tied to Wireshark being installed, and there are multiple entries because it is significantly out of date. I also see that the local Guest account is a member of the Administrators group on this server, which really should not be the case. Several of these other items may clear with Windows Update. We can reasses these after updating if necessary. We can ignore these self-signed certificate findings for now since this host generates its own certificates. I am concerned about the medium-weak strength cipher suites like the TLS 1.1/1.0 since these are deprecated. We should plan to disable them. I also noticed that the CVE-2013-3900 was flagged. This is a security feature bypass in Authenticode signature validation that lets an attacker append malicious code to a signed executable without invalidating the signature, making a malicious file appear trusted. We should prioritize this. One additional item is the ICMP Timestamp Request Remote Date Disclosure. Although low severity, the host reveals its system time when responding to ICMP type 13 requests. This is primarily a recon aid, but precise time disclosure can support more sophisticated attack techniques later in the kill chain. The fix is simple and has minimal operational impact, so we will schedule it after the higher-risk items.
Luca: Understood. So our focus is Wireshark removal, protocol and cipher hardening, the CVE, the ICMP, and correcting the Guest account membership.
Danny: Correct and we should also get windows up to date.
Luca: Got it. The good news is most servers likely have the same set of issues. That should make remediation easier to standardize.
Danny: Agreed. Do you foresee any problems with disabling weak ciphers and old protocols?
Luca: I doubt it. We will run changes through the next Change Control Board. Removing Wireshark and fixing the Guest account should not be an issue. Those should not be on servers anyway. I will confirm with our sysadmins.
Danny: Perfect. I will start building remediation packages to make rollout easier.
Luca: Sounds great.
Danny: Oh I wanted to ask, do you have anything in place to actually fix the Windows Update related vulnerabilities, like do you have patch management already in place?
Luca: Yes. I'm not actually worried about that. We already have patch management in place. So Windows updates should be handled automatically by next week.
Danny: Excellent. I will document the best remediation approach for these findings and get back to you before the next CAB.
Luca: Sounds good. Talk to you soon.
Danny: Talk to you soon.
The server team received remediation scripts and scan reports to address key vulnerabilities. This streamlined their efforts and prepared them for a follow-up review.
The Change Control Board (CAB) reviewed and approved the plan to remove insecure protocols and weak cipher suites. The change will use a tiered deployment with a small pilot followed by a phased rollout and includes a tested rollback script.
Click to View Meeting Transcript
Meeting Transcript
Johnny (CAB Chair): Next on the agenda are several server-team remediations: 1) removal of insecure protocols, 2) removal of weak cipher suites, and 3) a CSV. Looks like Danny from the Risk department is partnering with Luca from Infrastructure on this. Luca, can you walk us through the technical aspects of the change?
Luca (Infrastructure): Normally I would, but Danny built the solution. Can he take this one?
Danny (Risk): Sure. Insecure protocols and weak cipher suites mean the system is still capable of negotiating and using some kind of algorithm or protocol that's been deprecated. If it connects to a server and the server only wants to use those protocols, its possible that the computer will use them. On Windows, these are controlled through the registry. It's a really simple fix. Our PowerShell script goes through and disables deprecated protocols (for example, TLS 1.0/1.1) and medium-strength ciphers, and ensures only current, secure options remain enabled.
Jack (Board Member): Yeah that sounds good, but what if something breaks? Do we have a rollback plan in place, did you even think about that?
Danny (Risk): Yes. First of all, we will use a tiered deployment. Starting with a small pilot, which is a very small group of computers to first test the remedations on. Then pre-production, then production where it goes everywhere. Each stage includes pre and post checks. We also have an automated rollback script per remediation that restores the prior registry state if any unknown issue appears. We will run within the defined maintenance windows and maintain open communication with stakeholders.
Jack (Board Member): That sounds good I guess. Since the changes are registry-based with a tested rollback, I am not to concerned I suppose.
Danny (Risk): Yep, exactly. Anymore questions from anybody?
Luca (Infrastructure): None from me.
Jack (Board Member): No further questions.
Johnny (CAB Chair): Well then, do we all agree that the pilot and phased rollout is Approved?
Jack (Board Member): Yep, agreed.
Luca (Infrastructure): Agreed.
Johnny (CAB Chair): Great! We will review results at the next CAB meeting.
The server team used a PowerShell script to enable certificate padding validation to prevent signature spoofing. A follow-up scan confirmed successful remediation.
Powershell: Certificate Padding Script
Scan 2 - Enable Certificate Padding Validation
The server team used a PowerShell script to remove outdated Wireshark. A follow-up scan confirmed successful remediation.
Powershell: Wireshark Removal Script
Scan 3 - Third Party Software Removal
The server team removed the guest account from the administrator group. A new scan confirmed remediation, and the results were exported for comparison.
PowerShell: Guest Account Group Membership Remediation Script
Scan 4 - Guest Account Group Removal
The server team used PowerShell scripts to remediate insecure protocols and cipher suites. A follow-up scan verified successful remediation, and the results were saved for reference.
PowerShell: Insecure Protocols Remediation Script
PowerShell: Insecure Ciphers Remediation Script
Scan 5 - Ciphersuites and Protocols
Windows updates were re-enabled and applied until the system was fully up to date. A follow-up scan verified the changes.
The server team remediated “ICMP Timestamp Request Remote Date Disclosure” by using a PowerShell script to block ICMP timestamp traffic (types 13 and 14) in Windows Defender Firewall with Advanced Security. A follow-up Tenable scan confirmed the finding is closed.
Note: The same scan surfaced two additional items (SQLite prior to 3.50.2 memory corruption, Windows Speculative Execution configuration). They are out of scope for this round; in practice they would be triaged, prioritized, and assigned for remediation and verification.
Powershell: ICMP Timestamp Remediation Script
Scan 7 - Post ICMP Timestamp Remediation
During the first full remediation cycle, total vulnerabilities decreased by 83%, dropping from 30 to 5 across seven scans. All critical and high vulnerabilities were remediated (100% resolution); except for the 'critical SQLite prior to 3.50.2 memory corruption' which popped up during the last scan. Medium vulnerabilities declined by 76% and low findings were fully cleared by the final scan.
These results reflect strong coordination between operations and security teams, demonstrating effective patch validation and follow-up scanning. In a production setting, future remediation cadence would incorporate asset criticality and risk scoring to further refine prioritization.
After the initial remediation cycle, the program shifts into Maintenance Mode to keep risk low over time. Regular scans, continuous monitoring, and timely remediation continue per the cadence defined in the Finalized Policy.
Key activities
- Scheduled vulnerability scans: Run recurring scans (weekly or monthly) to detect new issues as systems change.
- Patch management: Apply security updates on a regular cadence. Handle critical items per policy-defined timelines.
- Remediation follow-ups: Prioritize and track fixes based on risk and impact. Verify closure with follow-up scans.
- Policy review and updates: Revisit the policy periodically to align with current best practices and organizational needs.
- Audit and compliance: Perform internal audits and maintain evidence for compliance requirements.
- Stakeholder communication: Share regular status updates, risks, and blockers with remediation owners and leadership.
- Exceptions: Document risk acceptances with expiration dates and review them regularly.
- Metrics and reporting: Track time to remediate, percent closed by SLA, scan coverage, and recurring findings.
Maintaining an active vulnerability management process helps the organization stay ahead of emerging threats and sustain long-term security resilience.